With the proliferation of electronic file processing and digital graphic art design, the publishing industry has migrated away from traditional mechanical layout/pressing systems toward electronic-based publishing/pressing workflow systems. Prior to the use of electronic publishing workflows, publishers/printers were responsible for integrating content components (i.e., images, text, etc.) into a consolidated document for printing. Thus, the scanning of images, color reproduction, layout, and associated formatting were performed by the traditional printer or pre-press house. As electronic publishing workflow systems have become increasingly commonplace in order to work with contemporary electronic content creators and graphic artists, printing and publishing entities have lost the ability to standardize the preparation and editing of content components necessary for controlling the production/layout process.
Presently, electronic publishing workflows are subject to inconsistent content component standards and corresponding consolidated electronic file translations. For example, component files such as image and text files are produced by a variety of applications. These component files are then integrated into a page format or “consolidated file” such as a PDF, TIFF, XML, and/or POSTSCRIPT® formatted file. The consolidated file converts component files (i.e., raster and/or vector based) into a single format for acceptance by an output processing system. In order to provide an acceptable consolidated file, attributes such as font handling, color handling, resolution, target output device, and compression must be determined in advance, and may be different for the consolidated file than for the component files. Moreover, in order to edit the consolidated file components, it is often necessary to recreate the original file components and/or change the consolidated file type.
By way of example, as shown in FIG. 1, a diagram representing a generic electronic publishing workflow edit chain is shown having four stages A-D. Typical workflow edit chains may be simpler or more complex, however, than what is shown and described herein. The workflow or “edit chain” of FIG. 1 begins in Stage A, which is the document creation level, where a document originator creates the original document in a “native” application such as MICROSOFT WORD™, QUARK XPRES® or ADOBE INDESIGN®. This original document is referred to herein as the Native Application File (NAF1). The document originator then creates a first PDF document (PDF1) from NAF1, such as through a direct export from the native application through a host application, or by printing to a distiller.
At Stage B, the document originator may apply a preflight profile received from a service provider, such as a printing service bureau, and may initiate an edit session for the purpose of preflighting PDF1. Preflighting, as is known in the art, is an output system compliance analysis step that compares the document to a set of rules, such as formatting rules, printability rules, and the like, relating to the specific output device used for creating the document in its final physical or electronic form, for example. PDF1 may optionally be edited, creating one or more intermediate files (PDF2a,b,c . . . ) that may be individually saved and preflighted, resulting in a document (PDF3) that is sent to the service provider. Although preflighting by document originators is a growing practice, this step is not always performed. Even when preflighting is done early in the edit chain, the service provider and/or printer cannot currently ensure that the preflight was in fact performed, or that the correct preflight profile was used.
The service provider, such as a pre-press house, then receives document (PDF3), which may or may not be preflighted, from document originator in Stage C. The service provider may perform a preflight step, which may be an initial preflight step or a verification that the preflight step performed by the document originator. The service provider may also make a series of edits and subsequent preflights, creating one or more intermediate documents (PDF 4a,b,c . . . ). The service provider may make edits, for example, to correct problems identified by preflight reports, add printability marks, make last-minute corrections, and the like. The final document created by the service provider (PDF5) then passes to Stage D, where it is handled by the printer or electronic publisher. Stage D comprises the actual printing step, which may first include a preflighting step to verify that the file conforms to the printing requirements before creation of the final published document (PD), such as a physically printed document, or electronically published documents such as a document posted to an Internet website or incorporated into a CD-ROM. It should be noted that Stages B and C are optional, and that in some cases a document originator may merely give the native application filed (NAF1) to the printer, who creates the PDF, preflights it, and prints it. Because there is no way to tell if a document has been preflighted at all or preflighted using the correct profile, even if the document originator has properly preflighted the document, the service provider and printer typically duplicate the effort.
As can be appreciated, propagation of the component and consolidated files through the edit chain of the electronic workflow system necessarily demands that changes be made by a variety of operators interactively or automatically (without user intervention) in the workflow. Thus, to increase the effectiveness of correction tools in any stage of a PDF workflow, it is desirable to address two issues: document consistency and editing responsibility. While it is most efficient to make corrections immediately as they are identified, “late stage editing” in PDF creates an inconsistency between the final document and the native application document. Furthermore, the native application document may be modified without the modifications being transferred to the final document. Job reruns may require duplication of approved corrections and result in added risk. With a digital workflow lacking the signed proofs of a non-digital workflow, there is no easy way to preserve the job at various approval stages, making it difficult to pinpoint the origin of an error or modification after the fact. Thus, it is desirable to provide a system that can identify when, where, and by whom changes in a document have been made.
Accordingly, there is a need for a PDF editing and workflow management system in which efficiency is increased by encouraging preflighting at an early stage in the workflow and by securing a specific file at a known point in the workflow to eliminate unidentified tampering. Furthermore, it is desirable to provide a system that can ensure that a document complies with a specific preflight profile without the need to duplicate the preflighting step at each stop in the edit chain.